\chapter{Implémentation}
L'implémentation se compose en 4 parties. La définition du protocole de communication entre le client et le serveur, les techniques de cryptographie utilisées pour sécuriser les échanges, la construction des paquets, les mécanismes de sécurité et enfin les intéractions effectuées sur le pare-feu du serveur.

\section{Définition du protocole}
La définition du protocole de communication est très importante car c'est elle qui régis la compréhension des échanges et permet d'affiner au mieux leurs sécurités. Pour respecter les attentes que sont la performance et la sécurité, nous avons utilisé les 6 paramètres suivants au sein du protocole:\\

\begin{itemize}
\item \textbf{L'adresse IP de l'émetteur}\\
		L'adresse IP permet de nous assurer de l'identité de l'émetteur du paquet. De plus en cas de problèmes de sécurité tel que le rejeu nous pourrons avertir l'usager du danger potentiel qui entoure ces communications.\\
		
\item \textbf{Un timestamp}\\
		Cette valeur nous donne une information de la date à laquelle le paquet à été forgé.\\
		
\item \textbf{Un nombre aléatoire}\\
		Ce nombre codé sur 10 octets prémunis le serveur contre toute tentative de rejeu.\\
		
\item \textbf{Une liste des services demandés}\\
		Ce paramètre contient la liste des services auxquels le client veut accéder. Liste sous la forme "tcp/22:udp/12455".\\
		
\item \textbf{Une somme de hashage}\\
		Ce hashage qui porte sur l'ensemble des informations décrites ci-dessus authentifie les données reçues.\\
		 
\item \textbf{Un IV (vecteur d'initialisation)}\\
		Cette information est utilisée pour les techniques de cryptographie déployées pour sécuriser le protocole.\\
\end{itemize}

Au sein du paquet tous ces paramètres sont identifiés grâce à un séparateur qui les délimitent.

\newpage 
\section{Chiffrement et codage}
Il faut différencier le chiffrement du codage. En effet le chiffrement est une technique cryptographique qui vise \`{a} transformer un message en clair à l'aide d'une clef, dite "clef de chiffrement", le rendant totalement incompréhensible et inutilisable pour toute personne ne possédant pas la clef de déchiffrement. En revanche le codage d'information n'utilise aucune clef et peut donc \^{e}tre facilement décodé par une personne tiers. Dans notre cas le chiffrement à une dimension de sécurisation des échanges tandis que le codage permet de simplifier la représentation informatique des messages transmis. Cette section se scinde donc en deux parties, cryptographie et base 64.

\subsection{Cryptographie}
Tout d'abord un paquet est composé de deux parties, un vecteur d'initialisation et d'une autre partie regroupant l'ensemble des informations décrites dans la section 3.1, sans le vecteur d'initialisation. La seconde partie est la seule \`{a} \^{e}tre chiffrée. Pour ce faire le protocole utilise {AES}\cite{DaRi02} (Advanced Encryption Standard) comme cryptosystème.

\paragraph{}
\textbf{AES} est un algorithme de chiffrement symétrique par bloc. Il utilise donc un mode d'opération pour traiter les blocs de texte clairs et chiffrés de l'algorithme. La librairie \textbf{mcrypt} propose des fonctions permettant d'utiliser cette algorithme pour chiffrer un message. Dans notre cas le mode d'opération \textbf{CBC} (Cipher Block Chaining) est associé à AES pour crypté nos paramètres.

\paragraph{}
Comme expliqué ci-dessus, en cryptographie un algorithme de chiffrement nécessite une clef de chiffrement et de déchiffrement. Cependant \textbf{AES} est symétrique ce qui implique que la clef est la m\^{e}me pour chiffrer et déchiffrer. Les clefs utilisées par notre protocole sont composées de deux parties.\\
La première est générée aléatoirement à partir d'un mot de passe gr\^{a}ce à librairie \textbf{mhash}. Une fois générée celle-ci est sauvegardée dans un fichier qui sera partagé par le client et le serveur. On appelle cette partie le secret partagé.\\
Le deuxième morceaux de la clef est l'\textbf{IV} qui comme décris ci-dessus fais partis du paquet. Cette IV est généré aléatoirement à partir d'un mot de passe pour chaque paquet envoyé et augmente donc considérablement le niveau de sécurité de notre protocole. C'est pourquoi cette IV n'est pas crypté au sein du paquet car le serveur en a besoin pour former la clef finale à partir du secret partagé et ainsi réussir à déchiffrer les informations.

\paragraph{}
Le programme applique alors un algorithme de codage en base 64 sur les caractères résultant du chiffrement des informations et de la génératon de l'IV.

\subsection{Base 64}
Le codage en base 64 consiste à coder de l'information en utilisant 64 caractères simples disponible sur la majorité des systèmes. Une fois les informations cryptées et l'IV généré, le programme applique l'algorithme de codage en base 64 sur ces deux valeurs. Ces données sont ensuite concaténées et délimitées par un caractère simple spécifique. Le contenu du paquet est le résultat de cette concaténation et n'est donc constitué que de caractères simples.

\paragraph{}
De son c\^{o}té le serveur n'a plus qu'à séparer les informations utiles de l'IV puis d'appliquer l'algorithme de décodage de la base 64 sur chacune des deux parties. Le serveur peut alors utilisé l'IV pour décrypter les données utiles et agir en conséquence.

\newpage
\section{Forger le paquet}
Pour envoyer une requ\^{e}te SPA à un serveur, le client doit tout d'abord forger un paquet représentant cette demande. Les spécifications du protocole SPA exigent que la requ\^{e}te soit un paquet UDP.\\
Un paquet UDP contient 3 niveaux (suivant le modèle TCP/IP) :\\
\begin{itemize}
\item	Niveau 3 - Transport (UDP)
\item	Niveau 2 - Internet (IP)
\item	Niveau 1 - Accès réseau (Ethernet)
\end{itemize}

\paragraph{}
Chaque niveau possède des informations qui lui sont spécifiques, telles que les adresses des interfaces réseaux (@MAC) pour Ethernet, les adresses IP pour IP et les ports utilisés ainsi que le payload pour UDP.
Pour pouvoir forger les paquets adéquats, la librairie \textbf{Libnet-dev} dispose de fonctions compétentes. En effet cette librairie permet de forger des paquets personnalisables de A à Z.
\paragraph{} 
\textbf{Libnet-dev} propose deux modes de construction pour ses paquets, soit une construction totale, en prenant en main tous les niveaux, soit une construction partielle, en laissant à libnet le soin de créer de lui même le niveau d'accès réseau (Ethernet). La deuxième solution s'avère plus interessante puisqu'aucune donnée spéciale n'est présente au niveau Ethernet.
\paragraph{}
La partie la plus importante lors de la construction du paquet est le Payload. Le payload contient tous les paramètres décrits dans la section 3.1 qui vont servir à effectuer la demande SPA. Ces paramètres sont récupérés en fonction des arguments passés lors de l'exécution du client, concaténés et injectés dans le paquet.

%\begin{figure}[!h] %on ouvre l'environnement figure
%\includegraphics[scale=0.5]{SPAPacket.png} %ou image.png, .jpeg etc.
%\caption{Illustration d'un paquet SPA} %la légende
%\label{SPAPacket} %l'étiquette pour faire référence à cette image
%\end{figure} %on ferme l'environnement figure

\section{Réception du paquet}
Pour que le protocole SPA fonctionne complètement, le serveur doit se doter d'un dispositif d'écoute intensif du traffic sur le réseau. Pour se faire, le choix s'est porté sur la librairie \textbf{Libpcap} qui offre des solutions optimales à ce problème. En effet une boucle infinie permet d'écouter sans discontinuité le traffic sur le réseau, et ce tout en offrant la possibilité d'y ajouter des filtres tels que le protocole de transport utilisé ou bien n'écouter que sur un port de destination spécifique.
\paragraph{}
Une fois un paquet capté, le serveur se charge de l'analyser. Après le décodage du payload, le serveur peut récupérer l'IV qui va lui servir à compléter sa clé de déchiffrement.\\
Il peut alors décrypter le payload, identifier et stocker chaque parties du payload en vue des différents tests futurs portant sur la légitimité de la demande.
Une fois cette légitimité avérée, le serveur modifie le pare-feu afin d'autoriser l'accès au divers services demandés.
\section{Mécanisme de sécurité}
Le protocole SPA est un protocole mis en place pour augmenter la sécurité du réseau, il est donc tout à fait indispensable que celui-ci se prémunisse lui-même contre diverses attaques qui aurait dans l'optique d'outrepassé le système mis en place.

\paragraph{}
Le serveur dispose pour cela de plusieurs mécanismes de sécurité :\\
\begin{itemize}
\item Un mécanisme d'anti-rejeu.\\Ce mécanisme inclut une fenêtre des 15 derniers paquets reçus afin de comparer la somme de hashage du paquet courant avec celle des paquets stockés. Si le paquet possède une somme de hashage déjà présente, le paquet est considéré comme réjoué.
\item Un mécanisme de péremption.\\Ce mécanisme, simple et efficace, vérifie que le paquet reçu est plus récent que le paquet le plus ancien au sein de la fenêtre. La règle est simple, tout paquet plus vieux est considéré comme périmé et est donc ignoré.
\end{itemize}
\section{Interaction avec le pare-feu}
Pour que le système SPA soit efficace et utile, il est nécessaire de pouvoir intéragir avec le pare-feu de la machine afin d'autoriser ou non une demande.
Le pare-feu de la machine est réprésenté par \textbf{Iptables}.\\
Avant toutes choses, le pare-feu doit être configuré de manière à rejeter tous paquets sauf ceux issus d'une connexion déjà établie.


\paragraph{}
L'interaction avec \textbf{Iptables} possède deux temps, la première est l'ajout de règle autorisant l'accès à un service demandé, la deuxième est la suppression de cette règle lorsque celle-ci n'est plus valide. Ces deux interactions sont effectuées de manière identique, à savoir en utilisant la fonction \textbf{system()}.\\
Cette fonction prend en paramètre une cha\^{i}ne de caractère. Cette cha\^{i}ne de caractère sera exécuté comme si elle avait exécuté dans une console.

\paragraph{}
Exemple d'un client ayant l'ip 192.168.0.2 demandant un accès aux ports "tcp/22:udp/12344" à 16:00:00.
Les règles \textbf{Iptables} qui seront exécutées seront :\\
\begin{itemize}
\item iptables -A INPUT -p tcp -s 192.168.0.2 --dport 22 -m time --datestop $(date +'2012-03-23')T$(date +'16:0:10') -j  ACCEPT
\item iptables -A INPUT -p udp -s 192.168.0.2 --dport 12344 -m time --datestop $(date +'2012-03-23')T$(date +'16:0:10') -j  ACCEPT
\end{itemize}

\paragraph{}
La première remarque est que chaque service possède sa propre règle. Ceci est dû au fait qu'\textbf{Iptables} ne permet qu'un protocole de transport par règle, ou tous à la fois(tcp,udp et icmp), mais pas "TCP" et "UDP" sans "ICMP". Deux solutions se proposaient, soit faire deux listes pour répertorier les services "TCP" ou "UDP" et faire deux règles générales, soit une règle par service.\\
La deuxième option à l'avantage d'être plus rapide à implémenter, c'est donc elle qui a été choisie.

\paragraph{}
La deuxième remarque à faire est au niveau de la date qui figure sur la règle. Elle représente la date limite de validité de la règle (Ici 10 secondes à partir de la récéption de la demande). Ce procédé est une sécurité pour s'assurer que l'accès aux services soit limité dans le temps.\\
Cependant, \textbf{Iptables} ne supprime pas les règles inactives tout seul.

\paragraph{}
Pour résoudre ce problème, la solution comprend deux parties :
\begin{itemize}
\item Le stockage de toutes les règles Iptables exécutées. Le serveur maintient à jour une liste de toutes les requêtes SPA valides qu'il a reçu, comprennant des informations sur l'adresse IP, l'heure, et les services demandées. L'enregistrement ce fait juste avant l'appel système permettant l'ajout des nouvelles règles du pare-feu.
\item L'utilisation d'une alarme. Cette dernière est activée sur le serveur, toutes les 10 secondes. A chaque activation, le serveur parcours la liste des règles enregistrées et vérifie la date limite par rapport à la date actuelle. Toutes règles ayant une date limite inférieur à la date actuelle est supprimée du pare-feu via les informations enregistrées. La suppression de la règle se fait par la reconstruction à l'identique de la règle d'origine à une option près :
\begin{itemize}
\item Ajout : iptables \textbf{-A} INPUT -p tcp -s 192.168.0.2 --dport 22 -m time [...]
\item Destruction : iptables \textbf{-D} INPUT -p tcp -s 192.168.0.2 --dport 22 -m time [...]
\end{itemize}
\end{itemize}
